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METHOD FOR MAINTAINING INFORMATION ABOUT MULTIPLE INSTANCES 

OF AN ACTIVITY 

|01] A portion of the disclosure of this patent document contains material which is subject 
to copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent disclosure, as it appears 
in the Patent and Trademark Office patent file or records, but otherwise reserves all 
copyright rights whatsoever. 

FIELD OF THE INVENTION 

[02] The present invention relates to methods and computer systems for monitoring a 
workflow of a business or other organization. More particularly, the present invention 
relates to methods for viewing information about multiple instances of an activity and 
for maintaining that information. 

BACKGROUND OF THE INVENTION 

[03] Computers, and in particular, computer database applications, are used by businesses 
and other organizations to monitor and record information about an organization's 
activities. Often, the organization will have various processes or activities that must 
be performed, and which recur frequently. Indeed, it is common for an organization 
to have numerous instances of an activity in various stages of completion at any given 
time. As one example, a business may sell goods based on orders received from 
customers. An activity of interest may be fulfilling those customer orders; each 
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purchase order represents a separate instance of that activity. At any particular time, 
that business may have multiple instances of the activity (i.e., multiple orders from 
multiple customers) in various stages of completion. As but another example, a 
financial institution may loan funds to customers based on applications from those 
customers. An activity of interest may be the processing of a loan application to 
completion (i.e., approval or rejection), with each application representing a separate 
instance of the activity. At any particular time, there may be multiple loan application 
instances in various stages of processing. As yet another example, a governmental 
entity responsible for issuing permits may have multiple permit applications in 
various stages of being processed. 

l04 ] In order to monitor numerous instances of an activity, many organizations store 
information about those activity instances in a database program. In particular, a 
record or other data object can be created for each instance of the activity. A separate 
field or other component of the record is then established to hold a value for some 
type of information common to each instance. Using one of the previous examples as 
an illustration, a business selling goods may create a separate database record for each 
customer order. Within that record may be separate fields for the time the order was 
received, where the order was received, what was ordered, when the order was 
shipped, etc. Such use of a database program is often conceptualized as a table. Each 
instance of the activity is assigned a separate row (or tuple) of the table. Each type of 
information common to multiple instances is then assigned a separate column of the 
table. 
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[05] By placing data for each instance of an activity in a database table, it is then possible 
to analyze the data in various ways. As more and more records accumulate, however, 
the usefulness of a database can decrease. For a large business such as a goods seller 
receiving hundreds or thousands of orders per day, the number of records can reach 
into hundreds of thousands or millions. Each time the database is queried, a finite 
amount of time is needed to search a disk drive or other storage device. Similarly, as 
new records are created and existing records updated, a finite amount of time is 
needed to create or update each of those records. As the number of records grows, the 
time needed to find a particular record increases. In a business or organization having 
hundreds (or thousands) of users and hundreds of thousands (or millions) of database 
records, the latency for database system access can become quite substantial and the 
system disk(s) may become full. 

[06] FIGS. 1-3 provide a more detailed illustration of this problem, and also provide an 
example to build upon in the subsequent Detailed Description of the Preferred 
Embodiments. FIG. 1 is a flow chart showing processing of customer purchase orders 
. by a hypothetical wholesale business which sells goods to customers based on 
customer purchase orders. For convenience, the business will be referred to herein as 
"Business A." At block 1, Business A receives a purchase order and creates a 
database record for the purchase order; the time of order receipt is also entered. At 
blocks 2 and 3, additional data is input for record fields corresponding to quantity of 
product ordered and the purchaser's city. At block 4 a decision is made regarding 
whether the purchase order will be accepted. If not, an appropriate field of the record 
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is populated at block 5 and the time of denial recorded. If the purchase order is 
approved, the approval is noted. If the purchase order is approved, additional 
information may be entered (blocks 6 and 7). When the order is shipped (block 8), 
another field is populated with the time of shipment. Further data may be input at 
blocks 9 and 10 (e.g., the type of shipping container and the carrier). When the order 
is delivered, the time of delivery is input (block 1 1) 

[07] FIG. 2 is a table representing a portion of the database for purchase order instances of 
Business A. Each order is on a separate row, and each column corresponds to a type 
of data for an order. For simplicity, FIG. 2 only shows columns for some of the 
information collected in the flow chart of FIG. 1. Certain fields contain NULL 
values, indicating (in this example) that the value for a particular event is unknown 
because it has not yet transpired as to that particular purchase order. A typical query 
of this database might be "which purchase orders above $1000, and that were 
submitted last week, have not yet been approved or denied?" Such a query could be 
implemented via a SQL (structured query language) query on the table. 

[081 Appendix A shows an implementation of SQL code to create the table of FIG. 2 
("create table POJnstanceData") and a stored procedure to update the rows of the 
table in FIG. 2 ("create procedure PO.Primarylmport"). This stored procedure 
accepts a PONum argument that uniquely identifies a record corresponding to one 
activity instance (in this example, a particular purchase order), and one parameter for 
each column in the table. Multiple arguments of the stored procedure allow the name- 
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value pairs for the call to be accumulated in memory (based on the transactional logic 
of the application program collecting the data) before attempting to update or insert a 
record. Because of the processing overhead required for locking and accessing a 
database record, it is more efficient to update (or insert) in one command as much of a 
record as possible. The stored procedure first tries to override the non-null columns 
of the record by issuing an "update" statement, assuming that some data for a PO 
exists in the table. Here the function "coalesce" is used, which returns the first non- 
null argument. If no records were updated (@@rowcount=0), this is the first piece of 
information related to this purchase order, and a record is inserted with the value of all 
the arguments (even if they are null). 

[09] A stored procedure such as in Appendix A is satisfactory when relatively few users or 
programming threads are attempting to write to a table and when there are relatively 
few records. Unfortunately, and as shown in FIG.3, performance degrades over time 
as the number of records in a table grows. The solid line represents write 
performance, or the number of records that can be written per second, and rapidly 
drops to a low level. Conversely, the average Queue Length for disk I/O (dashed line) 
soon increases beyond acceptable limits. This performance degradation results from 
the increase in table size. When the number of records is relatively small, 
performance is initially limited by the speed with which the database server can 
perform transactions, which is in turn dependent upon the capacity of the server's 
central processing unit(s). As the number of records increases over time (e.g., as 
more and more purchase orders are received and processed), performance drops 
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Really. For example, a first execution of the update statement in the stored 
proceOure of Appendix A wou,d cause a portion of the tabic (FIG. 2, to be read from 
. disx (or other non-volatile nrentory source, into RAM (or other memory system). 
A8 ,„ng as the total number of records is smaU, me seer is ab,e to caebe mos, or a„ 
of.be quired data in system memory, .fa subsequent update requires access to a 
re c„rd already cached in system memory, .be server is no, requued to read me dtsx 
again When me number of the records exceeds memory capacity, however, each 
operation can requtre a pbysica, read of me dis, Depending on me hardware used, 
other queries agains, (or updates of, the tabic may be prevented while me disk ,s 
leing read. Ultimately, this causes unacceptab.y siow response rimes for all users. 
The problen, can be exacerbated when more complex manipulation of data tn the 
. table be performed, such as On-L.ne Analydca, Processmg (OLAP, and creation 
of OLAP cubes. 

SUMMARY OF THE INVENTION 
(1 „ The present invention addresses fhe above and other challenges associated with 
maintaining information abou, muUiple instances of an activity. In one aspect of the 
invention, separate database table, are maintained for dam corresponding to active 
instances of an organization, activities and for dam correspondmg to tnacttve 
„ of an org— activities. In another aspect, multiple database tables 
can be maintained for dam corresponding to inactive instances of an activHy. In still 
another aspect, data from the acttve instances table and one or morainactive tnstances 
tables are processed to generate combined analysis data. 

-6- 
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11 ,• . o»«fthe activity has an active 

~f an activity Each instance ot the acuvuy 
regarding multiple instances of an activity. * 

„ „hich in— abou. ft. to— » - * 

flrsl tab.e, a corresponding record in a second database Ub.e. 
„ „ mote — - nretbod — — . - - — - 

^ie Foreacbof.bereco^sde.e.ed^.hef.rs.-eafte, 
,he previously-created table. For each 

— — — — rr- 

^ds in the ftrs, table, generating a seoond OLAP 
^^oornbnting.efirstand^^^a^OUAPoubo. 
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|,3, These and other features and advantages of the present invention wiU be readiiy 
apparent and fully understood from the Mowing detailed desoription of preferred 
embodiments, taken in connection with the appended drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[14 , FIG. 1 is a flow chart showing processing of customer purchase orders by a 

hypothetical business. 
|I5 , FJO.iisaub.ercpresenUngapornonofadanabaseforahyponreUca.busines, 

„6, FIG. 3 is a graph showing degradation in database system performance over time. 

„„ FIG. 4 is a Mock diagram showing separate tables for active and completed instances 
data according to at least one embodiment of the invention. 

„„ FIG. 5 is an example, accordmg to a. leas, one embodiment of the invention, of a 
portion of a database table containing records for activities that are still in progress. 

„„ FIG. 6 is an example, according to a, leas, one embodhnen. of me invention, of a 
portion of a database table containing records for completed activities. 

m FIG. 7 is a b!ock diagram showing sepamte tab,es for active and completed instances 
data according to another embodiment of the invention. 
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(21] FIG. 8 is a chart showing flow of data processing for combined OLAP analysis of 
active and completed instances data according to at least one embodiment of the 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

(221 The present invention can be advantageously used in combination with the methods, 
apparatus and systems described in U.S. Patent Application Ser. No. 10/157,968, 
titled "Support for Real-Time Queries Concerning Current State, Data and History of 
a Process" and filed on May 31, 2002, the contents of which are incorporated by 
reference herein. 

(231 The present invention will be described by reference to Structured Query Language 
(SQL) instructions and other data analysis features found in the SQL SERVER™ 
2000 relational database management system (RDBMS) software and associated 
Online Analytical Processing (OLAP) services software available from Microsoft 
Corporation of Redmond, Washington. Although some aspects of SQL instructions 
that may be used to implement certain embodiments of the invention are described 
herein, other instructions, programming algorithms and procedures used to implement 
the invention will be apparent to persons skilled in the art once those persons are 
provided with the description provided herein. General descriptions of SQL 
SERVER™ 2000 RDBMS software and associated OLAP services software can be 
obtained from various sources, including Inside Microsoft® SQL SERVER™ 2000 
by Karen Delaney (2001 Microsoft Press) and Microsoft® SQL SERVER™ 2000 
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Books Ontine, avai.ab,e a, <h V .//www.micro S o«.co«hi„fo/ 
pro duc,doc/2000/>. The invention is no. .united to imp.ementa.ion using SQL 
SERVER™ 2000 RDBMS software and associated OLAP services software, and may 
be implemented nsing other types of RDBMS and OLAP software. 

|M1 The present invention win also he described by reference to RDBMS software (such 
as the aforementioned SQL SERVER™ 2000 software) operating on a server and 
accessed by one or more Cents. Such configurations are known in the aft and 
described in, e.g., the previous.y-incorpora.ed U.S. patent app.tcation .0/.57.968. 
However, , cUent-server configuration is on,y one exampie of a manner in whrch tite 
inve „ti„n can be intp,emen,ed. The invention can a.so be bnp.emen.ed in other 
physical system configurations. 

|J51 The present invention addresses many of the prob.ems discussed above by 
manning separa tt tab.es for da. correspondurg to active instance* of an 

m a„y organizations, for examp,e, me most important activities are tirose which a« 
current., pending or which were recentiy compieted. Bunding upon the examp.e o, 
Hypothetic. Busiuess A discussed in connection with FIGS. .-3, managers of 
Business A are most interested in purchase orders mat are 8 ti„ behrg processed, ,e„ 

pure hase orders that were comp.eted within a re.ative.y recen, period (i.e., the ordered 
goods dehvered were deUvered withm dte .as, severa, months). A.though Business A 
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.mmon for — — o * concen-ed - — « - - <■ — 

of « an. organs - - WW, — of an - « 

■ „^^.^-^^-^ e - ,, - d,,,,,, ™ , 



the activity. 



1M1 Ac «« y , Bnsmeas A — - * - - -* — — " 
^ of^^^a.aU.^na^.a^ 

does no, degrade aa shown in HO. 3, and performance for acceaaing a completed 

i of FTfi 3 overall performance remains steady over 
updated. Unlike the example of FIG. 3, overa. p 

Table 10 holds records for 
ttaK FIG 4 ia a block diagram illustrating tins concept. Table 

^perra.nlng.oac.ivepurcbaaeoraera.^ee^ple.apnrcbaaeoroeriaaenve.f 
^orderedbyapurebaseoraerbaveno.yetbeend.Hvered.oacs.onte,^ 

Onceaptncb.eoraeriscornpleteM.ufor^purcbaaeoreerisn.oveotoUblen. 
taA e eM mp,e,apo K baae order ,s complex wben orderea gooda are delivered toa 
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As wirh acuve insrances, conned — of an organ— -»* 
could be defined differently in other contexts. 

SinriUr .o the raMe of FIG. 2, rah.e .0 has -vidua, records (..,, rows) for each 
purch ase order and individua. fie.ds (conunns) for various rypes of dam. In *. 
exanrp.e, "PONu*- is a purchase order nuruher. "RecvW is rhe dare aud rinre * 

purchas e order is locared, and «T is ft. nunrher of irenrs ordered. "ShipW 
„ A e dare and rime goods for a purchase order were shipped and «ime" .s 

As g oods for rhese purchase orders are shipped, dre "ShipTinre" fieid 

thata recurre„, ly ac.ive,i.e.,forwhich g oodshave„o,hee„de,ivered. According 
te .OeUvervTinr, fieid for each record has a NULL en,.. Tahie ,0 aiso has an 
a «ona, ne>d for an flag. An .sConrp.ereu vahre of 0 ind.cares rha, 

Ure copending purchase order has not heen conrp.ered. » some enroodinrenrs, 



- 12- 



Atty. Docket No. 003797.00623 

Patent Application 

&0 m active .stances data table .0, and a new — * - — " — 

„ completed — a- - " 4 >' ™ - - 4 U a dUP " Ca,e ° f 11,6 

Deli veryTime an, whhou, ,he ^Completed f,e.d. TO. 6 shows a portion of table U 
h „^ 8 ^-^-«»*-'-- fcB, - WW * ,,a " ert 

Mwy Time,. Because a pu^e order is defined in *e example .o be complete 
wh e„ the ordered goods are delivered, each of the DeliveryTime fields in .able .2 haa 
a non-NULL value. Table .2 has an additional fre.d for As deserihed - 

more de.au b*w, Oris valtse is incremental., general as eaeh reeord for a 
.mpleted purchase order is crearcd in table ,2. As seen h y comparison of the 
PONum and RecordfD fieids of FIG. 6, purchase oreera arc no, necessarily completed 
..h.anreorde^whichpnrchaseordernu.he^a^ed. The Record.* «> 
„idesamech ffl ism for ^records of uhie ,2 in dre order in whrchrhe 
reMrds were created. This ensures that insert performance w«, he independent 
table size, and therefore will not decrease over time. 

„ Because « is hmi,ed ,0 da. for purchase orders tha, a, enrtcntly active, the size of 

l„ivelv small Although the size of the table might fluctuate as 
table 10 remains relatively smalt, muio &■ 

«f ib- table will not increase ad infinitum. 
business volume fluctuates, the size of the table wtl 

H,« able 12 will grow in size as more purchase orders change 
completed instances data table tz win gi 
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ftom an M— p.ete - .o - * " " ^ 

* — -OS for - active and inactive — <- - « 
of nG 2> Because records are o„.y inserted into * 12 and are no, — — , 

record within table 12 before inserting a record. 

, Jt A^toh.PnofFIGS. 4-6 is included at 
,30, Oaeexamp.eofSQLcode.ocrea.eandupda.ed.euHesofFIO 

P0 Acnve te tanceDat,> crea,es «*. .0 for active -noes dara and es-s.es 
cotamS for POHum, , City, Quantity, SHipTtnre, DeUvetyTinre an 

«,ed. PONuurtsdes^atedaso.eprtu.arytrey. ,„ otner words, eac„ row of 

«. »«, stamen, ("create -e PO.Contp.etedtasUaceDa.", creates ta W e ,2 for 
c „ m p leK d .stances data and est-snea conantns for PONun, RecvTinte, 

^^epnn.aryteyand^venau— y nnc— vatue oy use of *e 

rw, .table 12) the database server automatically 
named PO_Completed_InstanceData (table 12), in 

i„e for RecordID and inserts the incremented value into the 
increments the previous value for Recoraiu 

added record. 
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pi, The next statement ("create procedure PO.Primarylmport") creates a Stored 
Procedure named PO.Primarylmport that is used to either create new records in table 
10 or to update existing records in table 10. The PO.Primarylmport Stored Procedure 
has 5 arguments that correspond to the columns of a row in table 10. For example, 
upon receiving purchase order 8680 in FIG. 5, a client computer would issue the 
following stored procedure call to the database server: 

PO_PrimaryImport (8680, 08/25/2003 17:19, Redmond, 270, , , ). 

If purchase order 8681 had previously been entered with data for PONum, RecvTime, 
City and Quantity, the following call to the stored procedure would update the 
shipping time (ShipTime) to 08/26/2003 0910: 

PO_PrimaryImport (8681, ,„ 08/26/2003 0910, , ). 

in order to update the record for purchase order 8682 to reflect a delivery time 
(DehveryTime) of 08/26/2003 at 1200 P.M. and flag the purchase order as completed 
(IsCompleted = 1), the following call would be made: 

PO_PrimaryImport (8682, ,,,, 08/26/2003 1200, 1). 

Notably, a human operator entering any of the above information into a client 
computer would not necessarily type one of the above commands. For example, the 
user could input the information via a graphical user interface, and one or more levels 
of intermediate software (executing on the client and/or server) would generate the 

-15- 
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rece , ved — y via the .tetnet, and we„ a- so^are con* - 
necessary SQL commands. 

M The PO Printer^ — ,~-» accepts vaioes - * can . the stored 
^e an, -p. - vaioes to one or .0. * the « — 
@R ecvTinte, «D**n. - ^nrpieted. 

PO Active —a * 0* .0) vU the W —f «— ° f 
^ Jose .oca, — - a «ew record hr -* * -eve, the * gg er 
Appendix C (.pO,Comple.edTriggeO is then fired. 

variab ,e, the *et assies v,nes to daose vatia.es front fc ^-T 
lable Ue tnserted * is — a„ y generated * the database server, and 
— srores (in RAM or other s y s,etn .pernor,) cop.ca of the rows arfceted 
during the precedin, inset, — - - PO.P—por, storeri procedure. * 

a. tViP inserted table contains the 
PO Primarylmport stored procedure. In other words, the mserted 

. , if the oassed value of the IsCompleted bit is equal to 1, 
134] The trigger first tests to see if the passed 

u ^ fnr the oassed PONum value is completed. It tne 
which would indicate that the record for the passed 

values for the completed 
oic 1 the trieeer then inserts the values ioi 
IsCompleted bit equals 1, the trigger 
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12) Tfce PONon, vahae for .he new table U reeorf ,s obtained «» the inserted table 

^ inserted**-'). The Wesee" ^ - - - ** — 

nw B b,e ,2 reooro fo, KeevT ta e, Chy, Sh,pT im e an. Dehve-yThne. In 

xtt tt t Tf qo that value is used for 
,he valoe of RecvTtae in the insert* table . non-NULL. If so, tha. 

PO P„port S ,o,edp— 

is ; s » re a » be non-NUtL by the code portion .sorted ,ef. ion. 

PC Move In— po on ^.PO^PONnn,". Specially, thta 
p^on of to bigse, coae speoif.es d,a, the va.es fo, the agents in each can of 

of the PO Active InstanceData table (table 10) in 
"inserted" table plus all of the rows of the PO_Active_ 

If „ e„np,e, <he PO.P»rt — P-do, was coiled ,o pass no, 
„ by fhe fhne an, data fo, the pocchase „.de. was « -ed into *. 
verted table. If, howeve, ,e PO^Iotport P,ocedo.e was eaUed ,0 
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op date an exisring record in .able .0 for wWch .here aheady exists a vaine for 
RecvTitn. (i.e., a value for RecvTitne was not passed in the PO.Printaryhnport stored 
procedure ca..), the valne of RecvTnne ft fte new Ub.= 12 record would eonte fton, 



the existing record in table 10. 



M After obtaining values for RecvTime, fte nigger singly obtains values of the new 
(ab ,e 12 record for fte CUy, Quan««y, ShipTime and DeliveryTitne fields. As 
pr evions, y discussed, the server —ricaUy supplies a va.ue for dte RecordU, field. 
The .rigger ft. dde.es .he record in Ubl. 10 for fte corned purchase order 
(■delete fton, PO>criveJnsta„ceDa,a where PONurn-@rONun,">. A, ft.* poin,, 
the trigger concludes ("return")- 
m ,f an UCon.ple.ed value of 0 was passed in fte FO Priftaryftnpor. stored procedure 

PO Prunatfmport stored procedurt- ("update PO MriveJnstanceData"). As ,„ the 
portion of fte nigger tha. creates a new record in table .2, fte coalesce fttnetion ts 
US ed ,o provtde a va.ue fo, fte upda.eu tab,e 10 record fton, eifter fte inserted .able 

po join inserted on po.PONu m =ftsert=d.PONu m ». Specifically, ftis portion of fte 
r^er code specifies fta. fte vah.es for fte coalesce ft.nc..on argumen«s w,,l be 
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• .• „ „f .11 n f the rows of the PO Active InstanceData table 
obtained from a set consisting of all of the rows _ 

(table 10) and of the "inserted" table having the same value for PONum. 

,37, If the PO Primarylmpor, stored procedure (Appendix B) was called to add a new, 
non-completed record ,0 table 10 (,..., inserting a record for a new purchase order for 
which goods have no, ye. been delivered), no values are updaled in the "update 
PO Active tastanceDatt" portion outrigger code. In such a case, mere would be 
no existing record in table 10 where me value of PONum is the same as me value for 

. pONrnnintheinsettedBblcandmuamerewouldbenorecotdinUble .Otoupdate. 

,f no reeotd is updated in table 10 or insetted in table 12, die trigger detects mis with 
ft. @@rowcun. system function. Specifically, the @@rowcou„. function returns a 
val „e of 0 if is no rows were affected in the preceding update statement. If me 
@@r0 wcou„< function rerun* a 0, the "insert PO_Active_Instance D ata select " from 
insetted" potion of the bigger code inset* a new record in table 10 with values from 
the "inserted" table. 

, 3 „ b, another embodiment of die invention, die amount of data in me completed 
stances data table is touted. As indicated above, the grow* of this table (table 12 
m no. 4) is less of a concern than is me growth of a table such as table 2. However, 
table 4 will nonetheless continue » grow over toe. Even if no records in the table 
are ever updated (i.e„ records are only inserted), the table will eventually become so 
,arge that system disR capacity will be exceeded or queries against me data in die 
table will recuire an unaccepfcbly long time to complete. As previously indicated, the 
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pagers of Business A have define* <ha. complied purchase order dam is oMy 
needed fo, purchase orders .ha, have heeu re.a,ively recendy c„mple.ed. However, 
aeiedoa of records from .2 cau be ume-consunung. r» many software 
environments, such deierion mus. be performed on a row-by-row basis; a row-ioca 

row can require as much rime as inserting or updating a row. 

„„ Accordmgiy, and as shown ,„ FIG. 7, muU.pl. tab.es are created for Compieted 
.nstanee Dau. m Oris embodmrent, me code of Appendices B and C operates as 
previous* described .o deiete compleled purchase order records ftom rab.e .0 and 
ereare corresponding new records in tabic ,2. However, tabie ,2 is no, aftowed to 
p ow wrthou, Umi, At periodic imervais (e.g.. every month), .able .2 is renamed 

A new (and empty) table 12 having me o.d name of me renamed .able 
(•■PO Completed taslanceDaU,") is men created. From this point on, me .rigger 
inserts records into me new table. After another month (or olher preselected time 
period), this table is also renamed, and another .able .2 created. After a renamed 
.able has been .mined for a se,e«ed .ime period (e.g., six months), me endre mb,e is 
de.eted. Unhxe de,e.ing .nd.vidna, records, enure ables can be deleteri quickly, m 
„„e embodiment mb.es are removed using a SQL "drop Ub.e" command. When a 
eo mp ,e,ed insmnce dam .ab,e is delernd, d,e dam in ma. .able is no, necessarily lost. 
For example, me deleKd mb.e can be archived by ftansferring me dam in me <ab,e «o 
.ape or omer «ype of s,omge medium pnor ,o ca.ling me drop uble ft.nc.ion. ft, o«her 
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embodiments, instead of creating a new table .2 a, pertonic M a new .able ,2 
is created when the size of table 12 reaches a certain level. 

m so the, all data in the active tnstance and completed instance rahles can he 
conveniently viewed and q uetied (i.e., so that a separate q uery is no, necessa* on 
each individual table), the achve ^d completed hrstances .hies (or some desired sub- 
duping of those tables) can be combined into a partidoned view. In a, least one 
embodhnent, the tables can he combined with a -union all select • ..." SQL statement. 
This view combining the Uhles could be recreated each lime one of the complied 

instan ce da. .bles is dropped (or alternatively, each time a new complete, instance 

data table is created). 

1411 ln auofter aspect of the hrvention, da. from fte acbve and completed mstances tables 
aK further processed ro provide additional analysis data. 
Business A may wish to collecdvely analyze currently active purchase order da. and 
da . for recently completed purchase orders. Business A may, for example, w,sh to 
generate one or more OLAP cubes for fte combined da. Again, and 
notwiftstandhrg fte hypothedca, nature of fte Busies A used for purposes of 
explaining fte invention, actua, organs also have a need to generate OLAP 
cubes reflecting both active and completed instances of an organization's activity. 

[42) no. 8 shows, in a, .east one embodiment, a flow of data processing for combined 
OLAP analysis of acbve aud completed instance da.. A stored procedure 
(..Beg^ataProceasing-) is executeo a, penodic inter* e.g. nightly. Tnrs 
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procedure first creates a copy of the active instances data table (table 10). Because 
tins table is kept relatively small, this copy can be created relatively quickly. The data 
in the copy is then passed to a Data Transformation Service (DTS)(not shown) to be 
placed into a star-schema and then fully processed into an OLAP cube 30 for the 
active instance data. The BeginDataProcessing stored procedure also obtains a 
portion of the completed instances data that lies in an incremental window. In 
particular, each time the BeginDataProcessing procedure obtains completed instances 
data, the database server stores the RecordID value of the last record obtained. As 
previously discussed, this value was incrementally assigned by the server when the 
record was created. By referencing the stored RecordID value for the last completed 
instances data record obtained during the prior execution of the BeginDataProcessing 
procedure, only records that have been created since that prior execution are obtained 
in the current operation. The incremental window is implemented as a special view 
created on top of the partitioned view containing multiple tables/partitions for active 
and completed instances data. In this manner, the incremental window can contain 
data from more than one partition. If, for example, the BeginDataProcessing 
procedure is executed weekly, a new completed instances data table may have been 
created since the last execution of the BeginDataProcessing stored procedure, and 
data from multiple Completed Instance Data tables would need to be processed. In at 
least one embodiment, the BeginDataProcessing stored procedure obtains a copy of 
the active instances data table and records from the completed instances data table at 
the same time. Otherwise, purchase orders could be moved from the active instances 
data table after copying by the BeginDataProcessing procedure, but prior to obtaining 
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records from the completed instances dau table. Were this to occur, the same 
purchase orders would be process* twice and undermine the accuracy of the dau 
analysis. 

,43| The BegmDataProcessing procedure passes the incremental completed instances data 
records created since the prior BeginDataProcessing execution to the DTS. The DTS 
then places that incremental data into a slar-schema Iha. already contains dau from 
prior processing of completed instances data. The slar-schema for completed 
instances data (which now contains the incremental dan, from recent completed 
instances data records) is then used to update completed instances OLAP cube 32. 
Similar to the completed manures slar-schema, OLAP cube 32 contains information 
about records mat were processed in previous session, OLAP cubes 30 and 32 are 
then combined into a single virtual OLAP cnbe 34. The number of completed records 
for which OLAP cube 32 contains information may become very large over time. 
However, by incrementally processing completed instances data and combining the 
results of mat processing with previously-processed completed instances dau, OLAP 
cube 32 (and hence, virtual OLAP cube 34) can be generated in a relatively small 
amount of time. In other words, reprocessing of completed instances dau can be 
avoided. 

,44| Virtual OLAP cube 34 provides a user with a "snapshot" of the business containing 
information about both historical and in-progress (i.e., active) purchase orders. Dau 
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Transforation Service, (DTS) packages that process cubes 30-34 can be scheduled 
to ran at night or during other off-peak hours. 

,45] Although the invention has been described using a hypothetical business type as an 
example, it should be remembered mat the invention is no. limited to a particular type 
of business, organization or activity. Indeed, tire invention is no. limned .o 
implements in which completed ins«ance da<a is rationed on me basis of age of 
the complied instianee data, hrstead of mainti.in.ng data for purchase orders 
complered in the las. few months, another organization may use some other criteria 
for retaining inactive mstimce data for quick access. As merely one example, a 
surveying company may w,sh to quickly access dati, for several land parcels, but may 
only infrequently access data about other parcels. Accordingly, although specific 
examples of carding on, the invention have been described, .hose skilled in the art 
will appreciate that there are numerous variations and permutations of the above 
described systems and techniques mat fall within the spirit and scope of to invention 
as set ford, in the appended claim, These and other modifications are wilhin .he 
scope of the invention as defined by the attached claims. 
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APPENDIX A 

create table PO_InstanceData 

PONum int primary key, 
RecvTime datetime null, 
City nvarchar(50) null, 
Quantity int null, 
ShipTime datetime null, 
DeliveryTime datetime null 

) 

go 

create procedure PO_PrimaryImport 
( 

@ PONum int, 

@RecvTime datetime=null, 
@City nvarchar (50)=null, 
@Quantity int=null, 
@ShipTime datetime=null, 
@DeliveryTime datetime=null 

) 

as 

begin 

update PO_InstanceData 

S6t RecvTime=coalesce (SRecvTime, RecvTime) , 
City=coalesce(@City,City), 
Ouantity=coalesce (QQuantity, Quantity , 

where PONum=@PONum 
if @@rowcount=0 

end 
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APPENDIX B 

create table PO_Active__InstanceData 
( 

PONum int primary key, 
RecvTime date time null, 
City nvarchar(50) null, 
Quantity int null, 
ShipTime datetime null, 
DeliveryTime datetime null, 
IsCompleted bit 

create table PO_Completed_InstanceData 

RecordID int primary key identity, 

PONum int, 

RecvTime datetime null, 
City nvarchar(50) null, 
Quantity int null, 
ShipTime datetime null, 
DeliveryTime datetime null 

) 

go 

create procedure PO_Primarylmport 
( 

@ PONum int, 

SRecvTime datetime=null, 
@City nvarchar (50)=null, 
@Quantity int=null, 
@ShipTime datetime=null, 
@DeliveryTime datetime=null, 
glsCompleted bit=0 

) 

as t z 

insert PO_Active_InstanceData values ( 

@ PONum, 

@ RecvTime, 

@City, 

@Quantity, 

@ ShipTime, 

@DeliveryTime, 

@IsCompleted) 

go 
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APPENDIX C 

create trigger PO_CompletedTrigger on PO_Active_InstanceData 

instead of insert 

as 

begin 

declare @ PONum int 
declare @IsCompleted bit 

select @PONum=PONum, @IsCompleted=IsCompleted from 
inserted 

if (@IsCompleted=l) 
begin 

insert PO_Completed_InstanceData 
(PONum, RecvTime, City, Quantity, ShipTime, DeliveryTime) 
select 

inserted. PONum, 

coalesce ( inserted . RecvTime , po... RecvTime ) , 
coalesce (inserted. City, po. City) , 
coalesce ( inserted . Quantity, po . Quantity) , 
coalesce ( inserted . ShipTime , po . ShipTime ) , 
coalesce ( inserted . DeliveryTime , po . DeliveryTime) 
from inserted left join PO_Active_InstanceData po on 
inserted . PONum=po . PONum 

delete from PO_Active_InstanceData where 
PONum=@ PONum 

return 

end 

update PO_Active_InstanceData 
set 

RecvTime=coalesce ( inserted . RecvTime , po . RecvTime ) , 
City=coalesce (inserted. City, po. City) , 
Quantity=coalesce ( inserted . Quantity , po . Quantity) , 
ShipTime=coalesce (inserted. ShipTime, po. ShipTime) , 

DeliveryTime=coalesce (inserted . DeliveryTime, po . DeliveryTi 

me) 

from PO_Active_InstanceData po join inserted on 
po . PONum=inserted . PONum 

if @@rowcount=0 

insert PO_Active_InstanceData select * from inserted 

end 
go 



-27- 



